1. Field of the Invention
The present invention relates to transfer of signaling parameters, generated according to a prescribed source telephony protocol of a source network, to a destination network via a transport network having a transport protocol distinct from the source and destination networks.
2. Description of the Related Art
The existing telephony standard Q.764 by the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) specifies that typically two types of exchanges exist in a telephony network: a “Type A” exchange and a “Type B” exchange. The “Type A” exchange is configured as an interworking point, where one protocol is converted into another protocol. An example of a Type A exchange is an end office switch that converts between ISDN User Part (ISUP) and ISDN for PBX access. The “Type B” exchange is configured as a transit node, where ISUP messages are passed with essentially no modification. Examples of a Type B exchange include toll switches or transit switches.
Hence, existing switching requirements (according to ITU Q.764) specify that the Type A exchange, configured for terminating signaling traffic, be able to understand a received ISUP signaling message; if the received ISUP signaling message is not understood by the Type A exchange, then the signaling message is dropped. The Type B exchange passes all ISUP messages, regardless of whether the ISUP messages and/or parameters are unrecognized.
Existing Voice over Packet (VoP) networks, for example Voice over IP (VoIP) based networks implementing VoIP protocols utilizing Session Initiation Protocol (SIP) or H.323, are limited in their respective abilities of transporting SS7 signaling information from a source network, for example a TDM based PSTN network, to a destination PSTN system via the VoP transport network. For example, an edge device (e.g., an ingress gateway) serving as an interface between a TDM network and an IP network may filter certain parameters of ISDN User Part (ISUP) messages and transport a subset of ISUP parameters to a destination (e.g., an egress gateway). Consequently, many features implemented in a conventional TDM based public switched telephone network cannot currently be performed within an IP domain.
Further, concerns arise about the ability of the Voice over Packet (VoP) network to “appear” to a PSTN network as another PSTN switch in order to obtain transparency in transporting ISUP messages between ingress PSTN trunk groups and egress PSTN trunk groups.
FIG. 1 is a diagram illustrating a conventional internetworking arrangement 10 between a source PSTN switch (SW1) 12, a destination PSTN switch (SW2) 14, and a VoP exchange 16 configured for passing signaling messages between the switches 12 and 14 via respective trunk groups 22a and 22b. The VoP exchange 16 includes a VoP network 18 of distributed components 20 (e.g., 20a and 20b) that are effectively aggregated to operate as a single virtual telephone switch. The components 20 are geographically distributed, enabling voice, data, and signaling traffic to be transported more economically via the packet network 18.
The VoP exchange 16 includes an ingress gateway 20a and an egress gateway 20b so labeled with respect to the direction of call establishment for a given call. The ingress gateway 20a and egress gateway 20b may be implemented, for example, as media gateway controllers (MGC1 and MGC2) having respective associated media gateways (MG1 and MG2). A media gateway is a logical entity that controls media connections. A media gateway controller is a logical entity that manages the establishment of calls across the VoP network 18. The gateways 20a and 20b may be configured for operating either according to Session Initiation Protocol (SIP) per IETF RFC 3261 or H.323 protocol. The ingress gateway 20a is configured for sending and receiving signaling messages with the source PSTN switch (SW1) 12 via the trunk group 22a according to a corresponding source telephony protocol 24a (ISUP-X). The egress gateway 20b is configured for sending and receiving signaling messages with the destination PSTN switch (SW2) 14 via the trunk group 22b according to a corresponding destination telephony protocol 24b (ISUP-Y).
The VoP exchange 16 needs to appear to the adjacent switches 12 and 14 as a single PSTN switch; in other words, the VoP exchange must support the Type A/Type B exchange requirement according to Q.764 in order to provide ISUP transparency for calls between the PSTN switches 12 and 14. If the ingress ISUP protocol (ISUP-X) 24a and the egress ISUP protocol variant (ISUP-Y) are the same, then the VoP exchange 16 needs to function as a Type B exchange; consequently, messages or parameters are to be passed by the VoP exchange 16 if instructed by Message Compatibility or Parameter Compatibility information, regardless of whether the VoP exchange 16 does not recognize certain messages or parameters. In contrast, if the ingress ISUP protocol (ISUP-X) 24a and the egress ISUP protocol variant (ISUP-Y) are different, then the VoP exchange 16 needs to function as a Type A exchange; consequently, any unrecognized messages or parameters received by the VoP exchange 16 would be ignored.
However, since the VoP exchange 16 is implemented by distributed components (e.g., 20a and 20b), the knowledge of ingress and egress trunk group types is not at a central location (as in a PSTN switch), but rather is local to the respective ingress gateway controller 20a and egress gateway controller 20b at the edges of the VoP network 16. Further, origination/destination paths between respective ingress/egress gateways may vary on a call-by-call basis; hence, the ingress gateway 20a and egress gateway 20b cannot be preconfigured for Type A operations or Type B operations, the necessity for a Type A operation or Type B operation is dependent on the origination/destination path for a given call. Consequently, there is a concern that ISUP transparency cannot be attained by the VoP network 16.